COMMENT ⊗   VALID 00002 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	\\M1BASL30\M2BASB30\M3BASI30
C00018 ENDMK
C⊗;
\\M1BASL30;\M2BASB30;\M3BASI30;
\F1\CAug 18, 1981



Gary Kildall
Digital Research
POB 579
801 Lighthouse Avenue
Pacific Grove, CA  93950


Dear Gary:

\J
Sorry to be so late getting this to you, but things got a little busy:
we just had a baby --Michael John Davis-Allen-- on August 9, and Ruth had
been confined to bed with high-blood pressure the week before, so I've
been out of circulation for the duration. Everyone's fine now.

To review our conversation, there are two major topics of concern to me:
the effective marketing of the existing TLC-LISP for the Z-80, and the
timely development of the next generation of TLC-LISP for larger machines.

First, the Z-80 LISP is  alive and well, but selling poorly --about one-hundred
copies in all. I believe the major problems are lack of marketing and lack of
good introductory applications and texts.
The latter problem, I am trying to 
resolve by writing some non-trivial examples --a skeletal version
of Visicalc and a video game like "Packman" are up and running on
the Model-II TRS-80-- and an introductory book, based on LISP, LOGO, and Smalltalk
is condensing out of courses I've taught at Santa Clara University and a LISP
session at Bill and Sharon's WICS  earlier this summer.

The former problem --marketing-- has been
a real headache for me; as a one-person effort, and a technical, not
marketing person at that, the business of advertising, mailing and general
maintenance leaves little time to  develop the next product for larger
machines; and it is these larger machines that will support LISP-like endeavours
well. As you suggested, I'm enclosing a TLC entry for your Software Catalog,
and enclosing a couple copies of the current documentation. The documentation
clearly is not introductory, but is readable. 
As I mentioned, the September issue of Byte
is supposed carry a (favorable) review of TLC-LISP; it was initially scheduled
for March, but has been delayed.

There are now about three versions of TLC-LISP for the Z-80 (1) the vanilla
CPM version, (2) the video-version for the Model II that uses a simple
window system, and (3) a multi-bank version that uses 18-bit pointers and
bank-switching to address at least 32K of 32-bit LISP objects. The last
two versions are not yet released. This last version will map easily to
the segmented Z-8000 and probably the Z-800 when it arrives. With a bit
more work, the code will transport to an 8086.

The exciting aspects of the effort (and most frustrating because of funding
constraints) involve the development of a TLC-LISP for larger machines.
I have been promised government funds for over six-months now and have lost
hope that they will ever arrive. The alternative is to attract corporate or
investor interest and it occurred to me that your organization might be in
a position to help. The following paragraphs outline part of the venture.

The basic notions were covered in a marathon tutorial I gave at the last
Computer Faire (paper enclosed). The notions involved were functional programming,
AI applications, and their manifestations
in graphical programming in the sense of Thinglab, Visicalc, and the 
Culler-Fried system. The underlying theme throughout is the notion of "constraint".

What I wish to do is develop a series of graphical/constraint-based applications
using the next generation of TLC-LISP as the implementation vehicle. 
Though current LISPs supply a full range of traditional data types, they
suffer several draw-backs as systems implementation tools; the
Sussman-Steele LISP dialect, Scheme, addresses several of these issues, but several
still remain --a clean class/sub-class structure being one of them. 
I expect to implement a LISP-like language that incorporates 
solutions to many of the problems; I would
categorize the next TLC-LISP as "Smalltalk with parentheses", being loathe
to give up the practical and theoretical benefits that program-data duality
gives to LISP.

Of course, such a language is only a tool; it is the applications that will
 sell the tool. The most direct application is education, and the series of 
Santa Clara courses holds promise; I'm enclosing a short course description
for an undergraduate offering that I presented this spring. San Jose and
San Francisco State have shown great interest in continuing this program.
Perhaps more saleable applications involve the graphics and AI domains.
First, there is substanital work at MIT utilizing LISP as the implementation
vehicle for VLSI design (see the last issue of Computer Magazine on
High-Level Architectures). Their language, DPL, was used extensively in the
design and implementation of the latest version of the Scheme chip. DPL
with an appropriate graphical interface would make an attractive and useful
tool.

Second, there is the direct application of 
twenty years of experience with the Culler-Fried System. This system is
currently in use in the UCLA Physics department, utilized for research in
plasma physics as well as teaching applications; faculty at UC Irvine use
the system for teaching statistical methods. It is an elegant tool for
developing mathematical intuition by experimentation with graphical information.
Unfortunately the system has only been available on large mainframes, but
it occurred to me several months ago that current micro-computers have sufficient
computational capability, and are beginning to have graphical capability 
sufficient to support the Culler system in an inexpensive, personal setting.
This setting must support quality raster graphics, and would be greatly
enhanced  if it had color graphics. Recently I spoke with Glenn Culler
(a teacher of mine from long ago) and he is quite interested my planned
implementation. The people at UCLA and UCI have been quite helpful as well,
supplying documentation and course descriptions. The Culler system is a twenty year
old gem waiting for  today's technology.

In the past, the Culler system has been presented as a stand-alone graphical
programming system, typically implemented in machine language. I has occurred to
me that a more powerful, general purpose tool can be had by  embedding the
Culler notions in a general-purpose symbolic language like LISP. Then, for
example, one has the potential for combining the numeric elegance of his system
with the algebraic expressibility of a system like Macsyma. Since the vector and
array quantities that are requisites for the Culler system are to be supported
in the next TLC-LISP, and since  graphical capabilites will be an integral
portion of TLC-LISP I/O, such a combined system is well within our scope.

Besides the Culler system, we wish to support quality graphics
to capitalize on the growing interest in LOGO and Smalltalk. Color graphics
are the heart of the LOGO philosophy, and give LOGO the immediacy that makes
it more approachable that its predecessor, LISP. Two books, \F3Mindstorms\F1 by
Papert, and \F3Turtle Geometry\F1 by Abelson and Disessa expose the educational
market to LOGO ideas, while Servan-Schreiber's \F3World Challenge\F1 discusses
the potential impact  of LOGO's ideas in a broader context. 
Of course, the impending release of Smalltalk-80 books and implementations
will also add fuel to LISP-related fire. Basically, any machine that is 
good for LISP will also be good for Smalltalk and LOGO; any discussion of LOGO
and Smalltalk will profit from and understanding of LISP ideas. Of course,
these are mutually profitable relationships.

As I said earlier, the tie that binds these applications together is the notion
of contraints: the idea that information within the machine expresses 
interrelationships that must be maintained as computations are carried out.
We see the beginnings (but only very weak beginnings!) of this idea in Visicalc.
We see much more elegant presentations of these ideas in Borning's Thinglab,
(written in Smalltalk) and some of the work of Sussman and colleagues in 
dealing with design languages (written in LISP
and Scheme). I forsee such systems --large internal
data bases equipped with "truth maintenance systems", coupled with graphical
input/output-- as the basis of what have been called "responsible systems".
Only then will we begin to see "user friendly" systems. 
Many of the pieces are already
available in the AI literature; the re-design, integration, and packaging
are still to be done.

This has been a somewhat long, involved letter; but I hope it clarifies a bit
of what I'm pursuing. The major difficult is that there's only one of me.
I'm not asking for a "cloning" operation, only exploring the possibility that
TLC and Digital Research together might be able to get me into a more 
productive mode. Joint ventures, contact with companies that might like
to see  such products on their machines, or contact with possible investors:
these are all possibilities that I'd consider.

Now that Michael has arrived and a semblance of order has returned, we would
soon be in a position (indeed relish the opportunity!) to come to Pacific
Grove and talk further with you and John Katsaros.
\.
\←L\→S\←R\-L\/'2;\+L\→L

Yours sincerely,


John R. Allen
18215 Bayview Dr.
Los Gatos Ca, 95030
(408) 353-3857
(408) 353-2227  TLC

\←S\→L